1. Field of the Invention
The disclosures herein generally relate to an information processing apparatus that runs a program having a step to display and receive a print setting condition, and a step to convert document data into print data.
2. Description of the Related Art
It is possible to send document data generated by an application on a personal computer by a facsimile machine. In such a case, the application calls a printer driver (precisely, it is a PC-fax driver, although it is called a printer driver here because there are a lot of common operations) that exchanges data with the facsimile machine so that a user can set an address or the like.
The printer driver provides a function to add a cover letter. Here, a cover letter is a sheet on which a sender, an address, etc., of the document data to be sent are explicitly designated, which is generated independently from the document data.
FIG. 1 is a schematic view illustrating an example of a cover letter. Here, a company name, a division name, a receiver's name, or the like are shown below the line of “To”, and a company name, a division name, a sender's name, a telephone number, a fax number, or the like are shown below the line of “From”.
If the function to add a cover letter is enabled when setting sending parameters of the printer driver, the printer driver starts a sending job by generating a cover letter data, then prints the cover letter data, and finally prints the document data. Thus, the cover letter is sent as a cover sheet of the document data.
However, it has been considered difficult for a user to set an address or the like after the user has started a fax sending job. To tackle this problem, several techniques have been proposed (see, for example, Japanese Laid-open Patent Application No. 2010-066876).
<Mechanisms for Printing on a Windows OS>
To explain conventional techniques, mechanisms for printing on a Windows (trademark) OS will be described first. As mechanisms for printing on a Windows OS, there are two spool formats, one is RAW spool format, the other is EMF spool format.
With RAW spool format, an application process executes a printing operation in which printing data from the application is converted to data that can be interpreted by a printer. From a user's point of view, the user cannot operate the application until the printing operation is completed.
With EMF spool format, an application process converts print data from the application to a device-independent EMF data format (intermediate data) to spool. And then, a spooler process executes a printing operation in which the EMF data spooled by the application process is converted to data that can be interpreted by a printer. From a user's point of view, the user can operate the application after the conversion to the EMF data by the application process is completed.
<Point & Print>
For a printer driver working on a Windows OS, there is an install format for a printer driver, called Point & Print.
FIG. 2 is a schematic view illustrating Point & Print. In a system in which a printer, a server PC, and a client PC are connected with each other via a network, Point & Print can be used for the client PC to execute a print job on the printer by using the server PC as a print server.
In such a system, the client PC needs to have the same printer driver installed as the server PC. It takes a lot of time and labor to install the printer driver on each of individual client PCs on a network.
Point & Print is a solution to this inconvenience, which is a mechanism for downloading and installing a printer driver from a server PC to client PCs. Point & Print is one of the standard functions of a Windows OS.
Having installed the printer driver on a client PC with Point & Print, a user can set whether a drawing operation is executed on a client PC or a server PC. Executing a drawing operation on a client PC is called client-side rendering, whereas executing a drawing operation on a server PC is called server-side rendering.
For a printer driver installed by Point & Print, there are RAW spool format and EMF spool format for printing.
Having described the background as above, three techniques that make it possible for a user to set an address or the like after starting to send a fax will be described below. However, each of the three techniques has its own problems.
1. Method for Adding Cover Letter Data by Drawing Driver
FIG. 3 is a schematic view illustrating a method for adding cover letter data by a drawing driver. A UI (User Interface) driver displays a screen for setting printing conditions before starting a print job, to receive the setting of printing conditions from a user. The drawing driver generates image data from document data reflecting the setting.
By adding cover letter data by the drawing driver, it is possible to add a cover letter when printing with RAW spool, EMF spool, and a printer driver installed by Point & Print. Here, the drawing driver has added a function to display a screen to receive the setting of printing conditions.
However, to add a cover letter data, the drawing driver needs to make a request to an OS with GDI (Graphic Device Interface) calls, such as TextOut( ) for drawing characters or the like. When the drawing driver operates, it operates under the system privilege of an OS. Therefore, making a GDI call may lower compatibility of the driver among OSes because some OSes may not receive a GDI call requiring the system privilege.
2. Method for Adding Cover Letter Data using DrvDocumentEvent( ) of DDI (Device Driver Interface) Provided with the UI Driver
FIG. 4 is a schematic view illustrating a method for adding cover letter data by a UI driver. In FIG. 4, the UI driver generates cover letter data with DrvDocumentEvent( ), which is stored in a file or a memory to be printed by the drawing driver.
Here, DrvDocumentEvent( ), a DDI of the UI driver, is used. In DrvDocumentEvent( ), a GDI is called. As the UI driver operates at the same privilege level as an application, compatibility is not reduced. However, the drawing driver and the UI driver are separate modules that cannot communicate directly with each other to exchange information, because a driver is basically just called by an OS through DDI.
Therefore, to exchange data between the UI driver and the drawing driver, a temporary file is used. The UI driver outputs generated cover letter data to a temporary file, and the drawing driver reads the temporary file, which makes it possible to exchange data between the UI driver and the drawing driver.
However, with this method using a temporary file, a file may not be output securely depending on an operation timing of a printer driver or a privilege level given to a user.
FIG. 5 is a schematic view illustrating a problem with using a temporary file. As shown in FIG. 5, in an environment where multiple applications are operating, there is a possibility that the setting written in a temporary file is overwritten. For example, cover letter data of an application 1 stored in the temporary file may be overwritten by another application 2 before the application 1 uses the stored data. From the viewpoint of the application 1, the content of the temporary file is changed after the cover letter data has been saved for the application 1 by the UI driver, before the drawing driver reads the content for sending the document data generated by the application 1.
To solve this problem, cover letter data may be saved in a print-setting storing module (for example, DEVMODE structure) instead of a temporary file.
However, even if using this method, there are two cases in which the problem cannot be solved:
2-1 Case with EMF spool
2-2 Case with a printer driver installed by Point & Print
2-1. Case with EMF Spool
Whether the module for storing a print setting can be used depends on a DDI call sequence for printing. It is possible with RAW spool.
However, with EMF spool, the DDI call sequence from a Windows OS is different. With EMF spool, there are two print processing sequences as internal operations within an OS, one is a processing sequence to convert print data from an application to EMF data, the other is a processing sequence to convert the EMF data to data that can be interpreted by a printer. Thus, the DDI call sequence with EMF spool is more complex than the sequence with RAW spool, which makes it difficult to exchange cover letter data at expected timings.
2-2. Case with a Printer Driver Installed by Point & Print
The method using the print-setting storing module can be used in a local environment where a printer driver installed on a PC used by a user.
However, if the printer driver is installed by Point & Print, and the printer driver is operated with server-side rendering, the UI driver operates on the client PC whereas the drawing driver operates on the server PC.
Server-side rendering, in the first place, uses physically separated PCs, hence the print-setting storing module exists only on the client PC. In this case, cover letter data cannot be exchanged because the drawing driver cannot obtain the sending setting from the print-setting storing module.
3. Method for Adding Cover Letter Data to a Device Context Received with DrvDocumentEvent( ) in the UI Driver.
FIGS. 6A-6B are schematic views illustrating methods for adding cover letter data to a device context. In this method, the UI driver directly adds cover letter data to a device context received with DrvDocumentEvent( ). From the application point of view, the cover letter data is added by the UI driver just before an actual document printing, hence one page seems to be added to the original print document.
With this method, the problem with the above method 2 does not arise because there is no data exchange between the UI driver and the drawing driver.
However, this method has a problem with 64-bit Windows OSes. As shown in FIG. 6B, a 32-bit application can operate on a 64-bit OS. For running a 32-bit application on a 64-bit Windows OS, a 64-bit Windows OS provides a mechanism called WOW64 (Windows on Windows emulation subsystem). On the other hand, a part of the device driver operates in the kernel mode, so it is made 64-bit compliant as the 64-bit OS itself. When printing, a 64-bit Windows OS runs a process called splwow64.exe as a function of WOW64.
In this case, there exist two different device contexts, one is the device context generated by the language monitor 32-bit application, and the other is the device context of splwow64.exe to which the UI driver makes write operations. Therefore, the UI driver cannot receive cover letter data.